home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ien
/
ien-165
< prev
next >
Wrap
Text File
|
1988-12-01
|
9KB
|
196 lines
USC / ISI Danny Cohen
3 January 1981 Jon Postel
W-note-23 Steve Casner
IEN-165
About addressing in the WBnet
-----------------------------
This note is written in response to W-note-16 (aka IEN-162, by John
Pershing) about a proposed addressing scheme for the WBnet.
We found the above note to be very well written, and it points out a
very difficult problem in internetwork addressing; however, we beg to
differ with some of the underlying assumptions, and therefore have
arrived at another proposal.
In this note we will first review the W-16 proposal, then present ours
and compare the two approaches.
The W-16 approach
-----------------
Assumptions and objectives:
- Whichever addressing scheme is used had better be compatible
with IP.
- There is a rich structure interconnecting hosts at all the
sites which are connected to the WBnet. This richness is
beyond what the processing nodes of the WBnet can be expected
to process directly - hence a hierarchical structure is
proposed.
- The richness of all the host interconnections at all sites
combined is similar to that of the catenet - hence a similar
solution should work.
- "To hide the physical structure of the Wideband Net from the
Internet and its gateways" - quoted from W-16.
- "To unify the transport and routing functions performed within
the Wideband Net" - quoted from W-16.
2
This yields the following addressing scheme:
Consider ALL the hosts on the ALL the local-nets which are connected to
ALL the WBnet gateways as being WBnet hosts, and assign them WBnet
addresses which reflect their connectivity to the WBnet as shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28. | Subnet Number | Reserved for Subnet Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-bits 8-bits 16-bits
For example, if there are 4 Lexnets and one Voice Funnel, at some site,
then each of these 5 "things" is assigned its own subnet-ID.
We hope that the above is an accurate reflection of the proposal as put
forth in W-16.
The ISI approach
----------------
We, too, believe that there may be a rich structure of host
interconnections at each site. However, for the time being we expect
the number of hosts at each site to be small enough that 8 bits would
suffice for intra-site addressing.
We also believe that all of our hosts are constituents of the catenet,
not of any particular network, including the WBnet. By this we mean
that any host should be addressable via any of the catenet networks to
which it has a connection.
We would like to reserve 8 bits of the WBnet/IP address for local
addressing so that each host can be assigned a single local address.
This local address would remain constant independent of which gateway or
directly-connected host (if any) was being used as an intermediary.
Therefore, we propose that only 16-bit WBnet addresses be assigned to
hosts which are connected to PSATs, directly or through some transparent
"port-expanding" mechanism such as a Voice Funnel. These hosts are
either bona fide hosts or full fledged IP (and/or ST) gateways.
At ISI, for example, we will have probably one or two such hosts,
through which all the other hosts gain access to the WBnet.
We prefer to see IP (and/or ST) gateways, not WBnet gateways, playing
the various intra-site communication roles (like routing) regardless of
which transport mechanism was used to get to the site, either Satellite
or terrestrial lines.
3
Therefore we prefer the following addressing scheme:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Network | Addressing in that net | Local address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-bits 16-bits 8-bits
This allows traffic for any host at a site to arrive through any
existing gateway.
The details associated with the routing of intra-site traffic do not
have to be propagated outside that site.
Comparison of the two approaches
--------------------------------
We acknowledge that our approach has the severe limitation that it can
currently support only up to (about) 256 hosts per site. Please note,
this is a restriction on the number of hosts but not necessarily on the
number of voice terminals, since NVP provides another level of
addressing called "extensions".
We propose that when this limit is reached an extended addressing scheme
(along the lines of source routing) be used.
The W-16 proposal requires that WBnet-gateways be installed between all
the local networks in every site. It requires that any change in
connectivity of the local networks be propagated to all the WBnet
gateways, in all the other sites, and be stored in all of them. This, in
our opinion, does not really comply with spirit of hiding local details
from the global world, as stated as one of the objectives of the scheme.
We believe that our proposal meets the objectives stated at the
beginning of this note, at least as much as the W-16 proposal.
Especially it meets the requirement that the details of intra-site
communication are no one else's business. We think that as far as the
outside world is concerned there is no difference between using hosts
for port-expanding and using local networks, or any hybrid of these
approaches.
The W-16 scheme must know all about the intra-site communication
structure. This scheme also requires the development (and
implementation) of a Gateway/Gateway protocol, just as was done for the
catenet.
It is not clear to us at all why all of our hosts should pledge their
allegiance to W-16 addressing scheme and to the WBC for which it stands,
one network, indivisible (enough!!).
We would like to treat the WBnet just as another transport mechanism,
which should be used only when it is found to be the best alternative
for some communication requirements. For our communication system the
WBnet should be just another means of inter-site communication, not a
religion to which all of our internal gateways and bridges have to
subscribe.
4
Conclusion
----------
We recommend that only 16-bit addresses be used within the WBnet in
order to specify its hosts; and that these hosts be either bona fide
hosts or gateways into other networks, including intra-site
communication systems.
As long as intra-site addressing can be handled by an 8-bit field there
is an efficient and convenient way to incorporate this field within the
IP-address field in addition to the 16-bit WBnet addresses.
Referee's comment
-----------------
Under the assumption that 8-bit addressing is enough for all intra-site
addressing, and under the assumption that all the local networks at any
site share this address space and already are capable of communicating
among themselves (and do not need help from the WBnet in order to
achieve it) - the two approaches, W-16 and ISI's, are IDENTICAL.
The folks at BBN may treat each site as a single subnet and assign it a
single subnet-ID. On the other hand, the folks at ISI may assign unique
local addresses to each of their hosts.
Hence, the 32-bit IP-address of the host on the WBnet will be composed
of the following 4 bytes (in Big-Endian's order, obviously):
Byte#0 = 28., the net-ID of the WBnet, assigned by Postel.
Byte#1 = WBnet address: Site- or Subnet-ID, assigned by BBN.
Byte#2 = Reserved for future extensions
Byte#3 = Local address, assigned by each site.
We would also like to recommend that BBN assign the subnet-ID's in
bit-reversed order in order to maintain maximal flexibility for future
expansions which may occur at either end of the addressing scheme.